home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0110 / news.txt / 1_4fix_2.asc < prev    next >
Text File  |  1997-04-16  |  15KB  |  267 lines
  1.  
  2. Copies of the programs that accompany these documents can be found in the
  3. SIDE_TWO\TOS_1_4 folder.
  4.  
  5.  
  6.                             ---~~~~OOO~~~~---
  7.  
  8.  
  9. POOLFIX4 (Got to patch and get again and again... c'mon, Leila, gimme
  10. ========  a break - or: Reasons To Be Cheerful, Part 4)
  11.  
  12. Yep, it's true, TOS 1.4 is buggy. Well, ATARI has done something about
  13. it and released several fix programs to blow up your AUTO folder. A
  14. very... ahem... remarkable representative of this kind of programs is
  15. POOLFIX written by Allan Pratt which tries to fix a new bug in the pool
  16. manager. Allan released three versions of this program, and then he
  17. settled down with a long sigh of relieve thinking he did it right at
  18. last.
  19.  
  20. Well, he wasn't quite right. Allan's POOLFIX versions needed to be
  21. placed first in the AUTO folder because POOLFIX tries to locate
  22. some illegal system variables by following the TRAP #1 vector into
  23. ROM code. If any program occupies the TRAP #1 vector before POOLFIX
  24. shows up, things are messed up: POOLFIX refuses to install itself.
  25.  
  26. This isn't a big problem for most of you out there, but it is a
  27. problem for people using hard disk drivers and other programs that
  28. start up before AUTO folder programs and use the TRAP #1 vector
  29. for their own purposes. It is also a pain in the neck for everyone
  30. to be forced to re-order their AUTO folder once again, and as time
  31. passes by, you tend to forget which programs in the AUTO folder
  32. need to be started in which order, and soon chaos spreads.
  33.  
  34. I was faced with the problem when I realized that POOLFIX3 didn't
  35. want to install itself when my own hard disk driver (included in
  36. the book SCHEIBENKLEISTER), version 3.5, was running. This is due
  37. to the fact that I use the TRAP #1 vector in CBHD 3.5 (my HD driver)
  38. to do some DESKTOP.INF patching that my readers urged me to implement.
  39. The problem, however, could have been solved easily if POOLFIX would
  40. follow the official ATARI guidelines for XBRA completely. CBHD 3.5
  41. uses XBRA to notify other programs that it linked into the TRAP #1
  42. vector, and so it would be no problem for POOLFIX to follow the
  43. TRAP #1 XBRA chain into ROM. Allan, however, didn't think of this
  44. neat possibility - being able to follow the chain was, as far as
  45. I know, one of the main reasons for adopting the XBRA standard.
  46.  
  47. (The same problem occurs with FATSPEED, a freeware (?) GEMDOS
  48. speed-up for TOS 1.2; if the programmer of FATSPEED should read
  49. this some day, he or she should think of implementing this follow-
  50. the-chain-into-ROM-technique into FATSPEED, too. Tnx so much.)
  51.  
  52. As always, users are forced to do the patching themselves. In this
  53. case, I reassembled POOLFIX and inserted a full-blown XBRA algorithm.
  54. Apart from that, I optimized the program a bit so that it occupies
  55. lesser space in RAM than the previous version. It's also a bit
  56. shorter on disk, but since it uses 2 clusters as before, there's
  57. no speedup when booting. BTW: I used TURBO ASS for this job, a
  58. remarkably fast shareware assembler written by Markus Fritze and
  59. Sören Hellwig, Birkhahnkamp 38, 2000 Norderstedt 1, West Germany.
  60.  
  61. POOLFIX4, as I called it, has been tested successfully on my MegaST
  62. with TOS 1.4 in ROM, on my STE with TOS 1.6 in ROM, and with a 1040
  63. with TOS 1.2 (where it doesn't install itself since TOS 1.2 doesn't
  64. need the patch). If there are any incompatibilities with any programs,
  65. please tell me:
  66.  
  67.     Claus Brod
  68.     Am Felsenkeller 2
  69.     8772 Marktheidenfeld
  70.     West Germany
  71.     (049-)(0)9391-3206
  72.  
  73.     (e-mail: C.BROD@LINK-N (Zerberus net), soon also on FIDO and
  74.              Usenet)
  75.  
  76. This program should always be posted or copied with this documentation.
  77. I claim no rights on this program (how should I, most of the code
  78. is from Allan, who hopefully doesn't mind if I correct him this way),
  79. so it's freeware. Spread it. I said: Spread it! Did I say "spread it"?
  80. No? So I'll say it again: Spread it!
  81.  
  82. Sorry, Allan, but I HAD to do this for my readers. I will send ATARI
  83. a copy of this program, so that they may be able to use it as an
  84. official version (it's clearly better than the original). Let's
  85. wait and see if they want it.
  86.  
  87.  
  88.                                ---~~O~~---
  89.  
  90.  
  91.                               CTSPATCH.PRG
  92.                            Copyright (C) 1989
  93.                              by Bill Penner
  94.                              26 August 1989
  95.  
  96.  
  97.       CTSPATCH.PRG  is  a  program  to  fix  the  TOS 1.4 RS-232 RTS/CTS
  98.  handshaking  problem.   The  program  can  be run as an autorun program
  99.  (placed  in  an  AUTO  folder  and booted) or run when beginning to use
  100.  RTS/CTS handshaking.
  101.  
  102.       Outside  of  the Rsconf() command not allowing the RTS/CTS mode to
  103.  be enabled, the RS-232 routines in the TOS 1.4 (April 1989) ROMs appear
  104.  to  be  bug  free.  The problem with the RTS/CTS routines is due to the
  105.  internal  variable  indicating  the  past state of the CTS line and the
  106.  active  edge  interupt register for the CTS line improperly set up when
  107.  the  system  initializes  at  powerup.   CTSPATCH.PRG  simply  does the
  108.  initialization and exits.
  109.  
  110.       Even  with  this program, many programs may not work with RTS/CTS.
  111.  This is primarily due to the various programs being written on a system
  112.  in  which  the  RTS/CTS  routines  were not working (and causing system
  113.  crashes  when  enabled  with  older  ROM's)  and  so many programs will
  114.  automatically turn off RTS/CTS handshaking.
  115.  
  116.  
  117.                                ---~~O~~---
  118.  
  119.  
  120.                                 TURBO CTS
  121.                               Version 1.32
  122.                     Copyright (C) 1989 by Bill Penner
  123.  
  124.  
  125.       First  a  statement:   USE  THIS  SOFTWARE AT YOUR OWN RISK!  THIS
  126.  PROGRAM  MAY  BE  FREELY  DISTRIBUTED  AS  LONG  AS THE PROGRAM REMAINS
  127.  UNMODIFIED  AND  THIS  DOC FILE REMAINS WITH THE PROGRAM.  THIS PROGRAM
  128.  MAY  !!NOT!!  BE SOLD, HOWEVER, MAY BE INCLUDED ON CLUB DISKS WHICH ARE
  129.  SOLD  FOR  A  SMALL  FEE.   YOU  USE THIS SOFTWARE AT YOUR OWN RISK.  I
  130.  ASSUME  NO RESPONSIBILITY FOR ANY LOSS, DIRECTLY OR INDIRECTLY FROM USE
  131.  OR POSSESION OF THIS PROGRAM.
  132.       Since  the  ATARI  ST  was  released in 1985 the computer has been
  133.  advertised  as  supporting  RS-232  Clear  to  Send and Request to Send
  134.  (CTS/RTS)   protocol.   The  truth  is  that  the  computer  never  has
  135.  sucessfully  supported this.  Even with the changes taking place in TOS
  136.  1.4,  the  April version of the ROM's still contain several bugs in the
  137.  RS232 routines which have made RTS/CTS flow control inoperative.
  138.  
  139.       Currently  most  RS-232  interfaces only require three wires to be
  140.  connected  between  the  computer  and a peripheral (such as a modem or
  141.  serial printer).  These lines would be the transmit data, receive data,
  142.  and  ground.   The  transmit data line would carry the information from
  143.  the computer to the peripheral device and receive data would bring data
  144.  into  the  computer  from the peripheral.  Some devices operate slowly,
  145.  such  as  printers,  and the computer can send out data faster than the
  146.  device  can  use  it.   To  be  able  to work best with a computer, the
  147.  external  device  normally uses some form of buffering to store several
  148.  bytes  (characters)  of  data (sometimes up to 256K bytes or more).  If
  149.  the  buffer was always larger than the amount of information no problem
  150.  would occur, but most devices will allow you to send more data out than
  151.  the  buffer  would  be  able  to  hold.   To  handle  this,  a  form of
  152.  "handshaking"  is  required.   For  the  RS-232  interface  one  of two
  153.  protocols  of  handshaking  are  normally  used.   Currently,  the more
  154.  popular  one is the XON/XOFF protocol.  In this protocol, when a buffer
  155.  is  nearly  full, the device will send out a character as would be sent
  156.  out by pressing Control and S (Ctrl-S).  When the buffer has emptied to
  157.  some  point, the device will send out a Ctrl-Q to tell the other device
  158.  to  start sending again.  Communication with most BBS's will also allow
  159.  the  user  to  stop the sending of text from the BBS by pressing Ctrl-S
  160.  from  the  terminal  and  then  Ctrl-Q to continue the text again.  The
  161.  other protocol is an older one in which two more wires are added to the
  162.  RS-232 interface for RTS and CTS signals.  These operate similar to the
  163.  XON/XOFF  protocol  except  that instead of sending some data back down
  164.  the  line  to  tell  the  other  device to stop sending data, a line is
  165.  changed  from  low  to  high.  The line being sent from the computer to
  166.  tell  an  external  device  to  stop  sending is called Request to Send
  167.  (RTS).  The line coming from an external device to the computer to tell
  168.  the computer to start or stop sending is called Clear to Send (CTS).
  169.       With   most   peripheral   devices   being   smart   (based  on  a
  170.  microprocessor  or microcontroller), and the serial speeds being fairly
  171.  slow  (110 to 9600 baud), XON/XOFF was easier to implement and required
  172.  less   hardware.   But,  now  with  modem  speeds  increasing,  several
  173.  companies  are implementing RTS/CTS flow control.  The US Robotics 9600
  174.  and  14400  baud  modems  have  MNP data compression available when the
  175.  modem  to computer RS-232 speed is set at 19200 baud, but to handle the
  176.  19.2K  baud  speed,  the modem uses RTS/CTS flow control.  The ATARI ST
  177.  ROM's  have pretended to support this mode, but bugs in all versions of
  178.  TOS have prevented RTS/CTS from working, including the April version of
  179.  TOS 1.4 ROM's.
  180.  
  181.      Upon  the  request  of Don P. (STARBASE), I began to work on a fix
  182.  for the problem.  At first glance the problem was a simple one, only to
  183.  trap  the  characters  being  sent to the modem and check for CTS being
  184.  low.   I  wrote  a  couple of accessories and programs which did this.
  185.  They  were  called  CTSFX100,  CTSFX101,  CTSFX102,  and CTSFX103.  The
  186.  result is that they worked for some pieces of software like Flash and a
  187.  couple  of  other  problems.   While  working  on  the  program,  I was
  188.  optimising  routines and making the program faster.  This only resulted
  189.  in  showing  that my method of fixing the problem was greatly in error.
  190.  I  was  simply  grabbing  the characters as they were being sent to the
  191.  output  buffer  and  between the operating system, my software, and the
  192.  terminal or BBS program, the transfer speed was less then 19200 baud so
  193.  the  buffer  would  never get filled up and my filter was working.  But
  194.  after  optimising several portions, the speed increased to the point of
  195.  making  my  program  useless  since the buffer would fill up the output
  196.  buffer  and when CTS changed, my program would stop placing data in the
  197.  buffer,  but  then  the computer would continue to send out the rest of
  198.  the  buffer.  In the documentation I wrote with the program, I included
  199.  my  phone  number.   The  program was distributed on F-Net and within a
  200.  couple  of  days,  I  had  received  many  phone calls about fixing the
  201.  problem.
  202.  
  203.       I  have  been working on the problem for a couple of weeks now and
  204.  have  come  to  understand  that the problem has been around for a long
  205.  time,  and  little  has  been  done  to  resolve the problem.  The data
  206.  compression  mode of the US robotics was not able to be used and people
  207.  were  relying on ATARI to eventully fix the ROMs.  After generating the
  208.  CTS  Fix  programs,  alot of interest was stirred up to fix the problem
  209.  and it appeared to be time to fix the problem, once and for all.
  210.       The  approach was to take a close look at TOS 1.4 and to determine
  211.  why  it  didn't  work.   I  found  only  three  minor problems with the
  212.  software.   Two problems had to do with the software not being properly
  213.  initialized  and  a bug in the Rsconf() routine which would not let you
  214.  set  CTS/RTS  mode.   I  was  able to get the RTS/CTS to work PERFECTLY
  215.  simply  by properly initializing the MFP CTS active edge register based
  216.  on  current  CTS level, initializing a system variable which is used to
  217.  tell  the  software  if the transmit port was enabled or disabled (also
  218.  based  on  current  CTS level), and then setting the system variable to
  219.  enable  CTS/RTS.  Programs would work just fine until they tried to set
  220.  the  flow control, which would disable CTS/RTS and cause XON/XOFF to be
  221.  enabled or disabled.
  222.       A final program was written to replace the RS-232 routines used by
  223.  the  system.  This was the only way to create some software which would
  224.  work  with  any  version of ROMs.  Since the other modes of handshaking
  225.  worked  just  fine,  I decided to write some RS-232 routines which were
  226.  optimized  for  CTS/RTS  flow  control in hopes of also speeding up the
  227.  RS-232 routines.  The resultant program is called TURBOCTS.PRG.
  228.  
  229.       TURBOCTS  is  a program which can be either autobooted or run when
  230.  the  RTS/CTS flow control is needed.  Once the program has been loaded,
  231.  the  RTS/CTS  mode is enabled and can not be disabled without rebooting
  232.  the  system.   The Rsconf() command can be used to set the RS-232 speed
  233.  and  play  with the UART registers, but flow control settings will have
  234.  no  effect.  The program will also properly trap the printer operations
  235.  when  the  printer  output  is  sent  to  the RS-232 port as set in the
  236.  control  panel  or  the Setprt() command.  In beta testing, the program
  237.  has  resulted  in  increasing the average Zmodem transfer speed on a US
  238.  Robotics  9600  baud modem communicating with the ST at 19.2 Kbaud from
  239.  approximately  850  characters  per second (CPS) to 1100 CPS for nearly
  240.  30% improvement.
  241.  
  242.       Note  for  PC Pursuit Users:  You can continue to use the software
  243.  when calling through telenet.  At the @ prompt, type:
  244.                    @set ? 1:0,4:10,5:1,7:8,12:1 <ret>
  245.  During beta testing, a 20 CPS speed increase was noted using TURBOCTS.
  246.  
  247.       I would like to thank Don P (Seattle) and  Mark A for the support,
  248.  suggestions,  and  information.  I also appologize for distributing the
  249.  real  lousy  version  of  CTSFX10x  which  worked  for  some and caused
  250.  headaches  for  others.   If  you  have  a  copy  of CTSFX10x please do
  251.  everyone  a  favor  and  erase  it  (besides, TURBOCTS works better and
  252.  faster!).
  253.  
  254.       If  you  have  any  problems  with  the  program, please send me a
  255.  message  on  GEnie  (BPENNER)  or  by mail at: Bill Penner, 3235 Wright
  256.  Avenue, Bremerton, WA  98310.
  257.  
  258.  
  259.                               ---~~END~~---
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.